Security risks, such as allowing unauthorized access to a user's system, are inherent with many on-line activities. Therefore, security mechanisms have been developed to protect users' systems. For example, a user may download an on-demand application from the Internet and execute the application from within the browser. To prevent an unauthorized access to the user's system resources (e.g., a directory on the user's hard disk), the user's system is protected by “sandbox” security that is enforced within the browser environment. Sandbox security involves a limited, secure area of computer memory in which an application may execute, so that the application is prevented from accessing system resources that reside outside of the secure area.
In some circumstances, however, a user may wish to allow a downloaded application controlled access to certain resources within the user's system. For example, a user may wish to use an on-demand word processing application to generate a document and then save the document to a directory in the user's system.
Existing approaches for providing such applications with secure, controlled access to a user's system are too cumbersome and inflexible. In one method, for example, a security policy is defined within a policy database in which a given application is associated with a permission set. The security policy, in combination with origin information, signature information, and access restrictions, helps define a “trusted” relationship between the application and the user's system.
Consider the following example:
grant codeBase “http://www.BobsWidgets.com” signed byBobsCertificate {permission lang.io.FilePermission “/tmp/” “read”;permission lang.io.FilePermission “/tmp/bwdir/*” “write”;}
In the example, an applet from the source location, “www.BobsWidgets.com”, is granted certain file access permissions if it is signed with a private key corresponding with a public key contained within BobsCertificate. An applet is traditionally a program designed to be executed from within a browser, rather than directly from within the operating system. The applet is granted permission to read files from the “/tmp” directory on the host system and to create and write to files in the “/tmp/bwdir” directory. Permission to “execute” is another common permission modifier. Other security policy specifications may, for example, grant broad permissions to access any file in any system location, regardless of the application's source or whether the application is unsigned or signed.
Existing approaches, however, fail to provide the flexible and dynamic functionality that is desirable during runtime. In the previously discussed example, a code assembly requests a set of needed permissions (“i.e., requested permissions”) from a global security method provided by the runtime environment. As shown, the permissions received by a given code assembly during a given runtime call chain are dictated by two characteristics: (1) the “CodeBase” or origin of the code assembly and (2) any certification received in association with the code assembly. These two characteristics define a “protection domain” in the exemplary approach.
The global security method described in the exemplary approach determines whether the requested permissions have been granted to a code assembly for a given protection domain. In addition, the global security method determines whether preceding code assemblies in the runtime call stack also have the requested permission based on the protection domain of each individual code assembly. The exemplary approach does not, however, allow customized security functionality to be incorporated into the security model. Instead, the approach is static, in that the characteristics that comprise a protection domain are limited to only two parameters, which values are fixed by the security policy.
Moreover, a given code assembly cannot dynamically influence the permissions received by other code assemblies in the call stack. For example, assume a first code assembly, which has been granted a permission to access a given file, calls a second code assembly, which has also been granted permission to access the file by the security policy. The developer of the first code assembly, however, may wish to prevent the second code assembly from accessing the file in this particular call chain. Existing approaches do not provide flexible means for a calling code assembly to dynamically influence the permissions provided to a called code assembly (i.e., so as to preclude the second method from accessing the file in the example).